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ABSTRACT: On February 1st , 2010 U.S. President Barack Obama submitted to Congress his proposed budget 
request for Fiscal Year 2011. This budget included significant changes to the National Aeronautics and Space 
Administration (NASA), including the proposed cancellation of the Constellation Program . This change proved to be 
controversial and Congressional approval of the program’s official cancellation would take many months to 
complete. During this same period an end-to-end discrete event simulation (DES) model of Constellation operations 
was being built through the joint efforts of Productivity Apex Inc. (PA1) and Science Applications International 
Corporation (SA1C) teams under the guidance of NASA. The uncertainty in regards to the Constellation program 
presented a major challenge to the DES team, as to: continue the development of this program-of -record simulation, 
while at the same time remain prepared for possible changes to the program. This required the team to rethink how it 
would develop it ’s model and make it flexible enough to support possible future vehicles while at the same time be 
specific enough to support the program-of record. This challenge was compounded by the fact that this model was 
being developed through the traditional DES process-orientation which lacked the flexibility of object-oriented 
approaches. The team met this challenge through significant pre-planning that led to the 44 modularization ” of the 
model ’s structure by identifying what was generic, finding natural logic break points, and the standardization of inter- 
logic numbering system. The outcome of this work resulted in a model that not only was ready to be easily modified to 
support any future rocket programs, but also a model that was extremely structured and organized in a way that 
facilitated rapid verification. This paper discusses in detail the process the team followed to build this model and the 
many advantages this method provides builders of traditional process-oriented discrete event simulations. 


1. Introduction 

The Constellation Program was a human spaceflight 
program initiated by the NASA Exploration Systems 
Mission Directorate (ESMD) and first developed 
through the Exploration Systems Architecture Study 
(ESAS) in response to the Vision for Space 
Exploration announced by President George W. Bush 
on January 14, 2004 and the NASA Authorization Act 
of 2005. The goal of this Program was to design and 
build a suitable replacement for the Space Shuttle to 
send astronauts to the International Space Station 
(ISS), and eventually towards missions to the Moon 


and Mars. To achieve these goals, the Constellation 
Program was developing the Ares I and Ares V 
rockets, which would carry the Orion Space Capsule 
and the Altair Lander, respectively, into space. The 
Ares I-Orion vehicle would have a dual use: alone it 
could transport Astronaut crews to the ISS or it could 
rendezvous with the Altair Lander-Earth Departure 
Stage (Altair-EDS) in Earth Orbit for a long duration 
mission to the Moon or Mars. The Altair-EDS would 
be launched using the Heavy Lift Ares V launch 
vehicle. Ares I consisted of a single 5-segment Solid 
Rocket Booster and a liquid-fueled second stage 
powered by a J-2X engine. Above the second stage, the 



Orion capsule would sit with a Launch Abort System 
attached to it. Ares V consisted of two 5-segment Solid 
Rocket Boosters and a liquid fueled Core Stage 
powered by multiple RS-68 engines the Earth 
Departure Stage with the Altair Lander would be 
stacked above the Core Stage . Figure 1 shows images 
of the Constellation vehicles. 


complete the model and collect task duration 
information from Constellation (Level 3) project 
offices. This effort led to a first round of analysis using 
the model for the Program’s Integrated Design 
Analysis Cycle 5 (IDAC-5). The third phase, 

performed between November 2009 and August 2010, 
began the development of a simulation model of the 
Ares V-Altair architecture. 



Axes I AresV 

Figure 1. Ares I, Ares V, Orion, and Altair 


1.1 The Constellation Discrete Event Simulation 
Model 


To support the development of the vehicles used for the 
Constellation Program, a joint NASA, SAIC, and 
Productivity Apex Inc. (PAI) team was tasked to 
develop an end-to-end discrete-event simulation (DES) 
model (the CxDES Model) [1]. This model looked at 
Program operations from a NASA agency and cross- 
center (Level 2) perspective for the purpose of 
analyzing system-level performance (i.e., element 
production meets launch manifest demands, which 
must meet mission delivery expectations).The model 
was developed using the Discrete Event Simulation 
Arena (Rockwell Automation) software application and 
the supporting Ariana (PAI) graphical user interface. 
The first phase of the effort (May 2008 through April 
2009) focused upon development of the model for an 
Ares I-Orion architecture supporting the International 
Space Station (ISS). The effort was continued into a 
second phase from May 2009 - October 2009 to 


The ultimate objective of the simulation models was to 
assess multiple performance indicators for 
Constellation’s Ares I-Ares V system including, but 
not limited to, the number of successful missions that 
could be achieved within a certain time frame. The 
required scope of the models involved the 
manufacturing of the Flight Hardware Elements 
(FHEs), assembly and integration, offline ground 
operations, integration in the Vehicle Assembly 
Building (VAB), transfer to the launch pad and pad 
operations (pad flow and launch countdown), ascent of 
the launch vehicle, mission ops, descent, recovery, and 
refurbishment where applicable. 

A custom Ariana Simulation Interface, using the PAI 
commercial software, was developed and delivered as a 
graphical user interface (GUI) for the Arena model. 
Ariana allows the users to define simulation scenarios, 
populate the model with new data, run the model, view 
the output, and compare the output. A master Microsoft 
Excel sheet was also developed and delivered as a way 
to read manufacturing lead time and launch manifest 
inputs and write the output data after a simulation run. 
Input data included FHE (e.g., Ares I, Ares V, Orion, 
and Altair components and their sub elements such as 
Interstages, Forward Assemblies, Solid Rocket Motor 
Segments, Aft Skirts) ordering differential times and a 
flight manifest. Output included mission-by-mission 
event occurrence time (e.g., integration start time in the 
VAB), weather and technical scrubs by mission, and 
waiting time in the VAB for each FHE per mission. An 
.automated graphing Excel sheet was also developed 
that included (among other things) output graphs and 
plots of planned versus simulated mission times . 

The Ares I model’s level of detail was defined in the 
conceptual flow diagram (CFD) of the manufacturing, 
assembly, and the integration of the 5 main FHEs: 

1 . Orion Launch Abort System (LAS) 

2. Cargo 

3. Orion 

4. Ares I Upper Stage 

5 . Solid Rocket Booster (SRB) 



The Arcs V model’s level of detail was similarly 
defined in the CFD of its 6 main FHEs: 

1 . Composite Shroud 

2. Altair Cargo 

3. Altair Descent Module 

4. Earth Departure Stage (EDS) 

5. Core Stage 

6. Two Solid Rocket Boosters (SRB) 

1.2 A New Budget 

On February 1 st , 2010 U.S. President Barack Obama 
submitted to Congress his proposed budget request for 
Fiscal Year 2011, which proposed significant changes 
to NASA, including the cancellation of the 
Constellation Program. This change proved 
controversial and Congressional approval of the 
program’s official cancellation would take many 
months to complete. This period of uncertainty was 
problematic because officially Constellation was not 
cancelled until Congress approved the 201 1 budget, but 
for all practical purposes the program was coming to an 
end. Additionally, it was unclear what new program 
would take the place of the Constellation program. This 
left the CxDES team in a difficult position: 
development of the Ares V model had to continue but 
it would more than likely never be used because the 
program it was supporting was ending. The challenge 
facing the team at this point was to develop a model 
that met the requirements of the current program, while 
also making it readily adaptable to support any future 
programs. 

2. Modeling Methodologies 

Discrete event simulation is one of the most widely 
used methods for analyzing processes and systems with 
a proven track record in process analysis and planning 
in many fields and industries including manufacturing, 
aerospace, healthcare and transportation. Simulation 
modeling has shown an advantage over other analytical 
approaches due to its ability to assess the effect of 
input variability on measures of performance. It also 
allows the introduction of rare events that are not 
typically found in deterministic models. This may 
partly address the problems associated with poor 
estimation of system performance (e.g. launch rates, 
turnaround time, and cost). 

There arc several modeling methodologies in the field 
of discrete event simulation. The two most widely used 
methodologies are the process oriented and the object 
oriented. The process oriented simulation model is 
constructed by mainly employing the processes of the 
system modeled along with their interactions. The 


resulting model will consist of the end-to-end process 
flow of the system, along with other processing 
modules that are mainly used to capture the logic in the 
system being modeled. On the other hand, object 
oriented simulation is constructed by building the 
objects present in the system being modeled. These 
objects contain all the flows and logic present in the 
system. The end model consists of all the objects in the 
system along with the interaction between these 
objects. The benefit of this method is that once the 
objects are developed, they can be reused or 
customized. In the process oriented approach, the 
reusability is possible, but requires additional 
customization effort to work in practice. 

3. Predicting the Future and other Launch 
Vehicle Programs 

When the CxDES project started, one of the first steps 
the team took was to develop conceptual flow diagrams 
for both Ares I and Ares V operations. The Ares I 
CxDES model was built following the original 
conceptual flow models and was modified as plans for 
the program changed. When it came time to start 
development on the Ares V model, the team started 
following the same process; when the new NASA 
budget was proposed, reconsideration of the original 
conceptual flow diagram was required to maximize the 
utility of this soon to be built model, even if the Arcs V 
rocket was cancelled. To do this, all the possible 
futures for alternative launch vehicles were first 
considered based on the current policy environment. 
The following options were considered along with their 
impact on model development: 


Scenario 

Impact on CxDES 

1) Constellation 
continues, as if the 
President had never 
cancelled the program 
in the FY2011 
budget. 

Build the Ares V model as 
originally envisioned and 
eventually integrate it with the 
Ares I model. 

2) Constellation 
continues with an 
enhanced test flight 
program. 

Build the Ares V model as 
originally envisioned and 
eventually integrate it with the 
Ares I model. Modify the 
existing Ares I model for 
analysis to support the 
proposed test flights, as well 
as use the data from the test 
flight program to improve the 
fidelity of the data used in the 
models. 

3) Constellation is 
cancelled with no 

Stop all work on the models, 
collect all work done up to 


NASA program to 
take its place. 

this point, and store the 
information for future use. 

4) Constellation is 
cancelled and a new 
Heavy Lift Vehicle 
program takes its 
place. 

Archive the Ares I model and 
develop a model for the new 
Heavy Lift Vehicle using the 
Ares I model as the basis or 
start completely from scratch. 

5) Constellation is 
cancelled but an Ares 
I test flight program 
continues in order to 
test out a new 
vehicle’s common 
components. 

Modify the existing Ares I 
model to analyze the proposed 
test flights as well as use the 
data from the test flight 
program to improve the 
fidelity of the data being used 
in the models. Then, build a 
model for the new Heavy Lift 
Vehicle using the Ares I 
model as the basis or start 
completely from scratch. 

6) Constellation is 
cancelled and a 
modified test flight 
program is started to 
test out a new 
vehicle’s common 
components. 

Develop a model for the new 
Heavy Lift Vehicle using the 
Ares I model as the basis or 
start completely from scratch. 
Use the relevant data learned 
from the test flight program to 
improve the fidelity of the 
data collected for the new 
model. 


Review of these alternatives showed there was overlap 
among most of them (Figure 2). 



Figure 2. Venn Diagram of possible Constellation 
Program futures 

Because many of these options were equally possible, 
the team decided that the model needed to be flexible 
enough to allow us to fit into as many of these futures 
as possible. Based on the Venn diagram it seemed that 
the possibility that overlapped with the most other 


possibilities was option 6: Constellation is cancelled 
and a modified test flight program is started to test out 
a new vehicle’s components. In terms of the model, 
this meant the model needed to be of a Heavy Lift 
Vehicle, specifically an Ares V vehicle, but flexible 
enough to support changes to similar vehicles. This 
could mean adding or removing FHEs and their 
corresponding logic. This also meant that this model 
would be built separately without integration with the 
Ares I model in mind. 

Since this new model would need to be able to support 
multiple vehicle types, the team decided it was 
necessary to build conceptual flow diagrams for 
multiple vehicle types. The team built conceptual flow 
diagrams for a Falcon 9-Heavy with a Dragon capsule, 
a theoretical Ares IV with an Orion capsule, and an 
Ares I model indicating how it differs from other 
rocket types. In addition, the Delta IV and Atlas V 
designs were reviewed, along with other Heavy Lift 
Vehicle designs NASA was considering at the time. 
This exercise helped understand the differences and 
similarities in the vehicles. From this exercise it 
became clear that many of these vehicles had much in 
common from the level of detail required in the model. 
All vehicles had a section that would cany some form 
of cargo (human or not) and at least two or more 
stages. The major components would all integrate in 
one facility immediately before going to the launch 
pad. Any prior assembly of smaller FHEs would occur 
exclusively in each of the independent section’s flows, 
and once these smaller parts were integrated they 
would rarely, if ever, de-integrate. Overall, the main 
differences were one extra or one less FHE. 

4. A New Methodology 

Once this flexible approach to model development was 
decided, the next step was to determine how to make 
this possible. The previously developed model was 
built exclusively as an Ares I and Orion vehicle. 
Because of its complexity, it would have required 
extensive work to modify for another vehicle. The 
forthcoming Ares V model, on the other hand, would 
have to base itself on the Ares I model and at the same 
time be flexible enough to be changed quickly to 
another vehicle type. 

To better understand this new approach, the Ares I 
model was reviewed to determine the location of 
natural breaks in the model flow. These natural breaks 
were areas where the model could be “cut” so that 
entire sections could be removed without affecting 
other parts of the model. This “surgical analysis” of the 
model allowed the team to determine what areas of the 
model could be turned into “modules,” which would be 




self-contained components of the model. For example, 
one module in the Ares I model would contain 
everything from LAS major component manufacturing, 
transportation to KSC, LAS Assembly, and LAS 
Storage before entering the Vehicle Assembly Building 
for final integration. This section of the model does not 
have any logic that directly connects to logic for any 
other FHE and is self-contained. 

Other modules, like those related to Orion, had to be 
grouped in module “families,” which were made up of 
modules that were self-contained for the most part, but 
were associated with other modules in some way. One 
example of this was the Orion family of modules. In 
the Axes I model, Orion was made up of three different 
major components: the Crew Module (CM), the 
Service Module (SM), and the Spacecraft Adapter 
(SA). Each of these components could have comprised 
their own separate modules, but immediately after each 
individual module they would enter another module in 
which they would be assembled together. So, if the CM 
module was removed from the model, it would create a 
problem with the Orion Assembly module. As a result 
of this issue, the CM, SM, SA, and Orion Assembly 
modules would be considered as part of the Orion 
“family” of modules (see Figure 3). This would notify 
the developer that if the CM module was removed then 
some consideration would need to be given to the other 
members of its “family.” This could mean removal of 
the other sections in the family as well, or at minimum 
a slight modification of their logic. 



Figure 3. Module Families Example 


The other aspect of the Ares I model that became clear 
was the many signals used throughout the model could 
make it very difficult to easily change the model. These 
numerical signals were originally named based on the 
order they were created. This made it difficult to 
determine either the source of the signal or the 
receiver. If a developer wanted to change out entire 
sections of logic, it would be very easy to leave signals 


hanging, which would cause havoc in the operation of 
the model. It also was apparent that documenting each 
section in the model (within the model itself) would be 
important to clearly understanding what was being 
changed. 

From this exercise, it was determined that a flexible 
Ares V model could only be developed with diligent 
attention to the following: 

• all signals were extensively documented 

• module “families” were identified 

• sections of internal logic were generalized so 
that they were not specific to one piece of 
hardware or another 

The model was developed taking these lessons in 
mind. The model was organized in the software 
application modeling area in a grid-like format for 
easy access and reference (see Figure 4 and Table 1). 
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Figure 4. Model Longitudinal Grid-like Sections 


For documentation purposes, every module was labeled 
with a brief description of what this section of the logic 
entailed. 

For the flexible Ares V model, the following seven 
module families were created: 

• Composite Shroud Family 

o Composite Shroud Module: From 

manufacturing to storage before Altair 
Hazardous Offline Processing 

• Altair-Cargo Family 

o Ares V Cargo Module: From production 
to storage after processing 
o Descent Module (DM) Module: From 

manufacturing to before Altair Assembly 
& Close-out 

o Altair Module: From Altair Assembly & 
Close-out to after transport to VAB 

• Integrated Earth Departure Stage (EDS) 
Family 



o Integrated EDS Module: From 

manufacturing of Altair Adapter, EDS 
components, J2X, and Interstage to after 
transport to VAB 

• Integrated Core Stage Family 

o Integrated Core Stage Module: From 
manufacturing of Core Stage components 
and RS-68B to after transport to VAB 

• Forward Assembly Family 

o Forward Assembly Module: From 

manufacturing to after transport to VAB 

• Solid Rocket Booster (SRB) Family 

o SRB Module: From SRB segment 

turnaround, SRB segment manufacture, 
and Aft Booster Buildup 

• Mobile Launcher (ML) Family 

o ML Module: From ML initial inventory 
station to before ML stacking preps 

A very specific methodology was developed for the 
model signal numbering system. Each signal was 7 
digits long with the first two digits representing the 
FHE number called by the signal (e.g. 08 represents the 
J2X engine). The middle two digits represented the 
direction of the signal, with the first of these numbers 
representing the “from” location and the second 
number representing the “to” location (e.g. 41 
represents a signal being sent from column 4 to column 
1) (see Figure 4). These numbers work like 
longitudinal sections on a grid. The last three digits 
represented a serial number of a signal of that specific 
type. So, for example, Signal 0543001 will call FHE #5 
(the Composite Shroud in Table 2), the signal is sent 
from column 4 (the integration section of the logic) to 
column 3 (the assembly & pre-integration section), and 
it is signal number 1 of this type. The below tables 
show the columns used within the model and the FHEs 
represented by number. 

Table 1. Modeling Area Columns 


# 

Description 

1 

Manufacturing & Ground Ops 

2 

Assembly & Ground Ops 

~ 

Assembly & Pre- Integration 

4 

Integration 

5 

Launch and Space Mission 


Table 2. Numbering System for FHEs 


U 

FHE 

# 

FHE 

01 

Composite Shroud 

12 

Core Stage Components 

02 

Cargo 

13 

RS-6SB 

03 

Descent Module 

14 

Integrated Core Stage 

04 

Altair 

15 

Processed Integrated Core Stage 

05 

CS Altair 

16 

Fwd Assembly 

06 

Altair Adapter 

17 

SRB 

07 

EDS Components 

IS 

Aft Skirt 

OS 

J2X 

19 

RSRM Segments/Aft Booster 

09 

Interstage 

99 

SRB 

10 

Integrated EDS 

SS 

Mobile Launch Platform 

11 

Processed EDS 

20 

Integrated Launch Vehicle 


5. Findings from the Flexible Approach 

One of the detriments in following such a flexible 
methodology is that much more time is required for up- 
front planning. It is not a trivial effort in the modeling 
of a complex integrated system to determine what logic 
fits within a module, or what modules make up a 
family. In addition, developing a signal numbering 
system describing the origin, destination, and direction 
of a signal can also be difficult, and the layout of the 
model can help or hinder this. Also, while planning out 
the model, it is challenging to keep in mind many other 
possible configurations and ensure that the logic being 
implemented does not hinder modification into 
different forms. Fortunately, this up-front effort can be 
beneficial in the long run, and not only if changes to 
the model must be made to accommodate a new 
vehicle. It was found that this thorough planning, 
documentation, and modularization made the model 
extremely organized and easy to follow, which was 
extremely useful during the testing and verification of 
the model. The model’s organization made it simple to 
compare what was modeled versus what was originally 
planned in the conceptual flow, making verification 
easier. 

The most obvious benefit is that it should now be a 
simpler task to modify the model from one vehicle 
representation to another. 

6. Conclusion 

The uncertainty in the future of NASA’s Constellation 
Program presented a major challenge to modeling 
efforts required to continue the development of the 
current program-of-record, while remaining flexible for 
whatever future program replaced it. This required re- 
thinking the development of the model and making it 
flexible enough to support unknown future vehicle 
configurations, while at the same time remain specific 
to the program-of-record. The team met this challenge 
through significant pre-planning, including a “surgical 





analysis” on a previous model to better understand how 
the logic could most easily be sectioned off. This work 
led to the “modularization” of the model’s structure by 
identifying generic natural logic break points, the 
standardization of its inter-logic signal numbering 
system, and extensive internal documentation. The 
outcome of this work resulted in a model that was more 
readily modified to support any future rocket programs, 
and extremely structured and organized in a way that 
facilitated rapid customization and verification. 
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• Constellation 

continues, as if the 

President had never 
cancelled 


e program 
in the FY^Dl 1 budget. 

Impact on CxDES 

• Build the Ares V model 
as originally envisioned 
and eventually integrate 
it with the Ares I ‘model. 
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• Constellation with 

an enhanced test flight 
program. 

Impact on CxDES 

• Build the Ams V model as 
originally eflfpsioned and 
eventually integrate it with the 
Ares I model. Modify the 
existing Ares I model for 
analysis to support the 
proposed test flights, as well 
as use the data from the test 
flight program to imptove the 
fidelity of the data used in the 
models. 
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Scenariojtge^ 

• Constellation is 

with no 
NASA program to 
take its {dace. 

Impact on CxDES 

• Stop all work on the 
models, collect all 
work done up ‘to this 
point, and store .the 
information for future 
use. 
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• Constellation is but an 

Ares 1 test flight program 

ore 

continues in order to test out a 
new vehicle’s common 
components. 

Impact on CxDES^t 

• Modify the elRing Ares I model 
to analyze the proposed test 
flights as well as use the data 
from the test flight program to 
improve the fidelity of the data 
being used in the models. Then, 
build a model for the new Heavy 
Lift Vehicle using the Ajes I 
model as the basis or start 
completely from scratch. 
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components. 

Impact on CxDBjj^ 

• Develop a model for the new 
Heavy Lift Vehicle using the 
Ares I model as the basis or 
start completely from scratch. 
Use the relevant data learned 
from the test flight program to 
improve the fidelity cff.the 
data collected for the new ♦ 
model. 
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The AresJjlfodel was reviewed to determine 
the location of natural breaks in the model flow. 
These natural breaks were areas where the 
model could be “cut” so that entire sections 
could be removed without affecting other parts 
of the model. This “surgical analysis” of the 
model allowed the team to determine what 
areas of the model could be turned into 
“modules,” which wpuld be Self-contained 
components of the model. • ' ; 
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One of the detriments in following such a flexible 
methodology is that much more time is required 
for up-front planning. 

This up-front effort can be beneficial in the long 
run, and notronly if changes to the model must be 
made to accommodate a new vehicle. 

— It was found that this thorough planning, 

• documentation, and modularization made the model 
extremely organized and easy to.fol|pw, whjph was 
extremely useful during the testing and verification 


extremely 


during the testing 
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The outcgpe of this work resulted in a model 
that was more readily modified to support any 
future rocket programs, and extremely 

v, 

structured ^pd organized in a way that 
facilitated rapid customization and 
verification. 
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